In order to program a computer effectively, a computer programmer must master a number of commands, application program interfaces (API's), and data structures. This usually requires a large investment of time learning specific techniques to code common basic functions for a specific operating environment. These common basic functions include presentation of data graphically on the screen, presentation of data on the printer, and storage and retrieval of data via a database management system. The requirement for generating and testing primitive code to build these common basic functions reduces the productivity of the programmer whose primary focus is to develop the specific functionality of the application.
Another important aspect of programming is consistency in the user interface where multiple applications are developed for use in a particular operating environment. A graphic user interface (GUI) is a means through which a computer system communicates with users. The GUI provides an assortment of controls or graphic user interface (GUI) components that are available for use by applications in the presentation and gathering of data. A GUI component is a graphic element that is used to display and accept information from the user. An application may define additional user interface components. Application defined components characteristically behave similar to GUI components.. Common user access (CUA) is the definition of GUI components that should be the same across all applications. The definition is based on a set of generally accepted user interface design principles. It is optimized for ease of use and encourages learning by exploring. CUA is helpful to the user because once the user learns the procedures to implement commands for achieving particular results in one application, he can expect the same procedures to apply in other applications.
In a programming environment, the framework, interaction techniques and other characteristics for defining a CUA interface are determined by procedural code written by the application programmer to implement various responses to user actions. Differences in coding techniques and style from one programmer to the next make it difficult to insure consistency in a CUA. In addition, even if CUA is accomplished, the procedural codes developed by one programmer will differ from another thereby requiring individual testing of the same characteristic of the CUA in multiple programs.
Consistency in coding of CUA procedural code and common basic functions is therefore desirable to ensure thorough testing and quality control where multiple program authors with individualized coding styles each contribute to a package of applications. In order to achieve this consistency, procedural codes to maintain a CUA may be coded one time, then shared between multiple applications. Similarly, many common basic functions of each application may be coded once and shared. This increases the productivity of the programmer and also avoids duplication of effort in programming. In the past, sharing of common basic functions has been done by the use of code libraries. Code libraries have the advantage that a piece of code can be developed, tested and maintained "outside" of the application program. The program then links to this library and at link time the code is placed into the application's executable file. The disadvantage of this method is that all the programs that require this code will have it contained in their executable file. This increases the size of each application file and may present a problem where multiple applications are desired for use on computers with limited disk and/or memory space.
Runtime loadable control modules have been developed to provide shared code that can be used by a variety of applications. The shared code contains routines to aid the programmer in code development. These modules generally deal with one specific area of programming. One such runtime loadable control module is a database management system module that handles the reading and writing of data in a record oriented input/output method. Another runtime loadable control module is an operating environment module that provides the GUI of the particular operating environment for interaction with the user via the computer keyboard, pointing device, screen or printer. For example, in the Tandy DeskMate operating environment, the database management system module is referred to as the DeskMate Database Management System (DMDB) and the operating environment GUI module is referred to as the DeskMate Core Services Resource (CSR).
The advantage of using runtime loadable control modules is that they allow for the storage of code in one location that may be accessed and shared among multiple applications without the necessity for duplicating the code in each application program. However, runtime loadable control modules traditionally do not incorporate procedural code that wholly contains a CUA. Such code governing reactions between components on a screen in response to user action or input tends to be application specific.
In addition, runtime loadable control modules associated with the respective GUI and database management systems have historically been disjoint. Each of the GUI and database management systems of an operating environment are defined through separate and distinct API and data structures. In order to utilize both the GUI and database management systems, an application must contain code that separately manages each of the GUI and database management system's unrelated data structures. The application must also contain code to translate data from one set of data structures to the other set of data structures. The application must further contain code that defines the relationship between data that is stored on the disk and data presented to the user via the GUI common basic functions.